Integration of other systems and applications is an important feature of any server-based product that automates processes and manages data. In particular, with an enterprise resource planning (ERP) system there is often a need to support systems and applications that are based upon different programming languages. A client application based upon a particular interoperability standard, such as Component Object Model (COM), allowed integration with an ERP system based upon a programming language, such as X++, different from the programming language of the client application. The ERP system included an interoperability component which provided a mechanism for the client application to invoke client-side classes, provided an execution environment for client-side classes and allowed client-side classes to call server-side classes, and vice versa, where the client-side and server-side classes were written in a programming language different from the client application. For example, an ERP server having a COM interoperability component exposed X++-based ERP components to client applications that were written in a non-X++ programming language but based upon the COM interoperability standard. COM-based client applications could integrate with the enterprise resource planning server, despite different programming languages, and X++ code was executed from the COM execution environment.
In many cases, applications were built based on different type systems or datatypes (e.g., strings, decimal handling, values, etc.) than the type system of the ERP server. For example, applications were built based on managed code. Generally, managed code is programming code that has its execution managed by a generalized multi-language, reflective execution engine, such as .NET framework Common Language Runtime (CLR). By contrast, any language that is not a managed code may be referred to as an unmanaged language, such as X++. Likewise, any application that is not based upon a managed code may be referred to as an unmanaged application. In some cases, “unmanaged” may also be understood as “native.” A managed programming language generally has a different type system than unmanaged programming languages. Accordingly, parameter types, data types, object types, etc. are different among managed and unmanaged programming languages and applications. As a result, an enterprise resource planning server should support different programming languages that utilize and support different type systems, such as managed and unmanaged programming languages, when interacting with applications and executing requests.
The unmanaged interoperability component, such as a COM-based interoperability component, did not have a managed application programming interface (API) and did not easily integrate with client applications based on managed code. In order to write managed code that interacted with the unmanaged interoperability component, managed applications utilized unmanaged (e.g., COM) wrappers around managed (e.g., .NET Framework) objects, and the unmanaged wrappers were used to interact with the unmanaged API of the interoperability component. The use of unmanaged wrappers required an additional layer of code in order to bridge the managed application and the unmanaged interoperability component, and increased the complexity of the managed application. Further, requests and data types from the managed application required mapping (also referred to as marshalling) from the managed application to the unmanaged interoperability standard (e.g., COM), and then from the unmanaged interoperability standard to the unmanaged programming code (e.g., X++) within the enterprise resource planning server. As a result, the use of wrappers was inefficient and ineffective because the managed application's usability and maintainability could be impacted, and the managed application's overall performance could be degraded.